新的一年又开始了

新年的第一个工作日，似乎没有什么不同，不过心理上总觉得与一年中的其他日子是有所不同的。工作目录依然在使用2023，不过确确实实是已经进入了2024年。

我会在每年的第一个工作日创建本年度的工作目录，不过刚开始的一段时间里并不愿意使用它，因为里面空空如也，想找个可参考的文档都要回到前一年的目录中去查找。如果把前一年的工作目录拷贝过来，那么几年之后，你的年度工作目录会变得十分臃肿，今后清理起来也十分麻烦，也不是一种好办法。工作是连续的，跨年只是一个仪式而已，为每年创建一个新的工作目录就像创建年度分区表一样，刚开始的几天总是容易出现执行计划错误，选错索引的情况。

今天和未来的2024年中的任何一个工作日都差别不大，与上星期五也没啥特别的地方。只不过今天在每个人的脑子里都会多一些期许，大多数人都会在这一天会为自己做一些祈祷，希望新的一年是希望实现或者起航的一年。

虽然跨年只是一个仪式，不过在年前的工作节奏也都会按照跨年仪式作为分界线不自觉地做了分割。在2023年的最后一周，我要求无论如何都要发布D-SMART V2的最后一个版本，我希望2024年，D-SMART要进入V3版本的时代。V3与V2最大的不同是大模型将会在今后的 D-SMART中发挥更大的作用。

其实在去年的4月份我就已经感受到大模型可以用来解决智能化运维中的一些目前很棘手的关键问题，也做了一些相关的尝试。不过因为本地部署模型的能力问题，很多实验虽然看到了效果，但是没有达到能够用于实际应用场景的水平，这项工作也因此被暂停了。大半年过去了，大模型的迭代发展也十分迅速，涌现出大批在运维领域比较优秀的大模型。不过目前大模型虽然在多轮对话能力方面已经表现出了十分优秀的性能，但是通识大模型在运维领域的能力依然偏弱。

去年11月份发布的OpsEval为通识大模型的选择提供了一个不错的基准，我们根据第一批公布的基于OpsEval的测试数据比较了几个可本地化部署的大模型在数据库运维领域的性能，发现OpsEval的评价还是基本靠谱的。去年我们参与了OpsEval基准的工作，为基准提供了一些数据库方面的测试题，今年我们将会加大这方面的力度，更多的参与其中。

在上个月我们重启了基于大模型的D-SMART自动诊断模块的开发工作，也利用一些模型做了一些尝试，从初步测试来看，对模型的微调依然是必须的 ，大模型对于zero shot场景的性能太差，差到无法完成所需的任务。虽然通过RAG嵌入向量后能够提升性能，不过向一个基础能力过弱的通识大模型提供向量嵌入能力，最终可能比直接搜索知识库好不了多少。幸亏在节前与一个客户的交流中获得了使用他们的GPU阵列资源的许可，让我们今年微调基础模型有了可能。尽快调优出一个基础模型将会成为我们今年V3版本成败的关键。

大模型不是今年想做的事情的全部，而只是一个完成今年主要工作的一个辅助工具而已。V3版本今年首先要对接的是GAUSSDB数据库，虽然目前D-SMART已经支持了GAUSSDB，不过是比较基础的支持，V2.5版本对分布式数据库做了框架上的优化后，我们先在Oceanbase上完成了对接。Gaussdb的功能也需要升级为与Oceanbase差不多的水平。这项工作的完成比为D-SMART加入大模型支持更加困难一些。因为这需要数据库原厂、数据库用户的积极参与才可以。在对接Oceanbase的时候，OB原厂和一些OB的用户都积极参与到我们的工作中来，为我们提供了大量的运维知识。在2023年的最后一天，我给华为软件生态部门的同学发了消息，希望他们能给予支持，令人高兴的是获得了十分积极的反馈。

2024年我们将继续致力于国产数据库产品与国产数据库运维技术的研究，并不断把研究成功纳入到D-SMART中去。我也会积极地参与各个数据库友商的活动与技术交流，也会继续在公众号里发表我的观点和看法。

我们正面临一个巨大的变革，这个变革是数据这个新生产要素带来的，数字化与智能化会对各行各业带来变革，这种变革的力量是最近几十年来前所未有的，无论对实体产业还是IT产业，都会产生巨大的影响。在这场变革里，一些传统大佬将会老去，甚至故去，一些新势力将会崛起。对于我们这个刚刚完成产业布局，建立了完善的世界工厂的国家来说，这场变革的冲击力尤其巨大，很多产业还没完成升级，就面临萎缩甚至淘汰，我也希望新的一年是这些行业破茧化蝶的关键一年。

对于数据库产业，对于DBA而言，这种转型压力也同样巨大，传统的知识体系、技术能力、工作经验都面临新形势的巨大挑战。要么去适应新的时代，要么就会被新的潮流吞噬。因此2024年对于DBA们来说依然是关键的一年，选择哪种方式去面对新的挑战，将会决定你未来的路走得顺与不顺。我想此时我所想，也是很多同行们正在思考的问题吧。